Skip to content

Fixed UDF jar metadata handling in UDFInfo when multiple UDFs share the same jar#17732

Merged
jt2594838 merged 4 commits into
masterfrom
udf-fix
Jun 3, 2026
Merged

Fixed UDF jar metadata handling in UDFInfo when multiple UDFs share the same jar#17732
jt2594838 merged 4 commits into
masterfrom
udf-fix

Conversation

@Caideyipi

Copy link
Copy Markdown
Collaborator

Description

This PR fixes UDF jar metadata handling in UDFInfo when multiple UDFs share the same jar.

Background

UDFInfo previously tracked uploaded jars only with jarName -> md5. When a UDF was dropped, the jar metadata was
removed immediately. This breaks the case where multiple UDFs reference the same jar:

  • dropping one UDF can make ConfigNode think the shared jar no longer exists
  • later validation may no longer detect conflicting MD5 values for the same jar name
  • after snapshot load, jar metadata is restored but shared-jar reference state is not rebuilt, so the same issue can
    reappear after restart

Changes

This PR introduces reference counting for shared UDF jars in UDFInfo.

  • add existedJarToReferenceCount to track how many UDFs are using each jar
  • update UDF creation flow to increase jar reference count instead of only recording MD5
  • update UDF drop flow to remove jar metadata only when the last reference is removed
  • rebuild jar metadata and reference counts from the UDF table after loading a snapshot

This keeps shared jar metadata consistent across normal create/drop operations and snapshot recovery.

Tests

Updated UDFInfoTest to cover the shared-jar cases:

  • dropping one UDF does not remove jar metadata if another UDF still references the same jar
  • validation still rejects the same jar name with a different MD5 after one reference is dropped
  • snapshot load rebuilds shared-jar metadata correctly, and subsequent drop behavior remains correct

This PR has:

  • been self-reviewed.
    • concurrent read
    • concurrent write
    • concurrent read and write
  • added documentation for new or modified features or behaviors.
  • added Javadocs for most classes and all non-trivial methods.
  • added or updated version, license, or notice information
  • added comments explaining the "why" and the intent of the code wherever would not be obvious
    for an unfamiliar reader.
  • added unit tests or modified existing tests to cover new code paths, ensuring the threshold
    for code coverage.
  • added integration tests.
  • been tested in a test IoTDB cluster.

Key changed/added classes (or packages if there are too many classes) in this PR

@codecov

codecov Bot commented May 21, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 98.91304% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 40.78%. Comparing base (7563ac8) to head (678ffa4).
⚠️ Report is 51 commits behind head on master.

Files with missing lines Patch % Lines
...mons/executable/ReferenceCountedJarMetaKeeper.java 98.38% 1 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##             master   #17732      +/-   ##
============================================
+ Coverage     40.55%   40.78%   +0.23%     
- Complexity     2574     2610      +36     
============================================
  Files          5179     5187       +8     
  Lines        349896   351466    +1570     
  Branches      44727    44999     +272     
============================================
+ Hits         141890   143339    +1449     
- Misses       208006   208127     +121     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

luoluoyuyu

This comment was marked as outdated.

@luoluoyuyu luoluoyuyu left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review summary

Reference counting for shared JARs fixes incorrect removal of existedJarToMD5 when only one of several UDFs is dropped. rebuildJarMetadataFromUDFTable() keeps jar metadata consistent after snapshot load. New unit tests cover the shared-jar and snapshot paths.

Two small suggestions below; otherwise this looks good to merge.

}

private void addJarReference(String jarName, String jarMD5) {
existedJarToMD5.putIfAbsent(jarName, jarMD5);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

putIfAbsent keeps the first MD5 for a jar name but always increments the reference count. That is fine when validate() runs before addUDFInTable, but if addJarReference is ever called without that check, ref count and MD5 could diverge.

Consider rejecting a conflicting MD5 inside addJarReference (same check as in validate() at lines 107-115) so this helper is safe on its own.

deserializeExistedJarToMD5(fileInputStream);

udfTable.deserializeUDFTable(fileInputStream);
rebuildJarMetadataFromUDFTable();

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After deserializeExistedJarToMD5, rebuildJarMetadataFromUDFTable() clears both maps and rebuilds from udfTable. That makes udfTable the source of truth on load.

A short comment here explaining that deserialized existedJarToMD5 is intentionally discarded would help future readers.

@jt2594838 jt2594838 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

May unify the jar management of UDF and PIPE (and even more).

Comment on lines +99 to +108
public synchronized void serializeJarNameToMd5AndReferenceCount(final OutputStream outputStream)
throws IOException {
ReadWriteIOUtils.write(jarNameToMd5Map.size(), outputStream);
for (final Map.Entry<String, String> entry : jarNameToMd5Map.entrySet()) {
final String jarName = entry.getKey();
ReadWriteIOUtils.write(jarName, outputStream);
ReadWriteIOUtils.write(entry.getValue(), outputStream);
ReadWriteIOUtils.write(jarNameToReferenceCountMap.getOrDefault(jarName, 0), outputStream);
}
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible or necessary to serialize an entry whose count is zero?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. A zero reference count should not be serialized: under the normal add/remove path, removeReference removes both maps when the count reaches zero. I updated the snapshot logic to serialize only entries with a positive reference count and matching md5 metadata, and to skip non-positive counts when loading snapshots as a defensive cleanup. Added a regression test for the zero-count snapshot case as well.

@sonarqubecloud

sonarqubecloud Bot commented Jun 3, 2026

Copy link
Copy Markdown

@jt2594838 jt2594838 merged commit 709145c into master Jun 3, 2026
47 of 50 checks passed
@jt2594838 jt2594838 deleted the udf-fix branch June 3, 2026 08:53
jt2594838 pushed a commit that referenced this pull request Jun 4, 2026
… the same jar (#17732) (#17835)

* UDF Fix

* sp

* fix

* Filter invalid jar reference counts in snapshots
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants